Over the last ten years, corporate computing environments have evolved from monolithic proprietary mainframe computer systems to networks of decentralized heterogeneous computer systems. These distributed systems 20 typically include personal computers and work stations that offer productivity solutions with higher flexibility at lower cost.
At the same time, the cost and complexity of support has drastically increased. For example, the operating systems and applications software require periodic updates. Moreover, every different system configuration can require a 25 separate reinstallation of software, an operation which can be costly and time-consuming for a large installed user base.
The JAVA programming language was developed to encourage low maintenance application development by providing a machine-independent and architecture-neutral programming language capable of operating on heterogeneous computer systems independent of machine-specific environment and configuration settings. An overview of the JAVA programming language is described in P. van der Linden, “Just JAVA,” Chapter 1, Sun Microsystems, Inc (1997 2d ed.), the disclosure of which is incorporated by reference. The most common JAVA programs are applications and applets. Applications are stand-alone programs. Applets are similar to applications, but adhere to a set of interface conventions and run only within the context of a JAVA-enabled container, such as a Web browser. During execution, the container downloads the byte code required to run the applet as needed.
The Java programming language provides a convenient means for disseminating software updates using Zip archives or Java Archive (JAR) files. These archives and files can be used to deliver and directly run Java applications and applets. The Zip archives and JAR files are packaged in a Zip format that allows multiple files to be bundled as a single archive file. In addition, JAR files include a manifest storing attributes for each of the bundled files and can include an optional digital signature. JAR files are described in D. Flanagan, “Java in a Nutshell,” Chapter 24, O'Reilly and Assocs. (1999 3d ed.), the disclosure of which is incorporated by reference.
Although offering a convenient way to deliver JAVA program updates, Zip archives and JAR files create a problem, known as the “high water mark” problem. The high water mark problem results from the inability to deliver specific updates or patches to individual component files using a JAR file. Rather, when JAVA program updates or patches are delivered using JAR files, an entire JAR file is delivered, instead of just a single updated component file. Moreover, to ensure that each JAR file is current, the JAR file must always include the latest version of each component file. A single updated component file cannot be delivered and a complete high water mark JAR file must be delivered instead. Delivering a complete high water mark JAR file results in delivering many other potentially undesirable changes, which can include unexpected behavioral changes, or other highly destabilizing changes to the product.
To avoid the high water mark problem, JAVA program updates can be delivered in the form of individual files stored within an operating system directory structure. Each separate update or patch can then be delivered to effect individual changes without unanticipated side effects. However, this approach poses difficulties with file naming conventions. The JAVA programming language supports long file and class names which are language features not supported on every operating system. JAVA source and class file names can contain special characters, such as the dollar sign, which can cause portability concerns. Similarly, the JAVA programming language uses the Unicode character set, an internationalized character set that may not be fully supported on all platforms, potentially causing further portability concerns.
These individual update or patch files also introduce directory nesting concerns. JAVA packages are implemented as directories in a hierarchical file structure. Packages can be stored in deeply nested directories. However, the nesting depth can exceed the maximum permissible depth on a given platform. Consequently, these JAVA programming language-specific file naming and directory storage conventions limit the operating systems that can directly support single file updating and patching.
JAR files lack integrity controls for ensuring the proper application of updates and patches. The order in which updates and patches are applied should not ordinarily determine the end result of the application. However, JAVA updates and patches can be generated and applied in any order. Moreover, neither JAR files nor individual patch and update files include a revision control mechanism to ensure that out-of-date class files do not overwrite the latest versions.
Inner classes further complicate JAVA program updating and patching. A single JAVA source file that uses the JAVA “inner class” construct can produce multiple JAVA class files. Inner classes make tracking out-of-date JAVA class files difficult.
Finally, other issues arise when patching and updating JAVA applets. Applets are generally loaded into a JAVA-enabled browser in a JAR file format. Some applets must be signed with a digital signature to work properly. Consequently, the JAR file in which applets are delivered must be signed. If a JAVA application being updated or patched requires a signature, either the signed high water mark JAR file must be delivered or the JAR file must be assembled and signed at the customer site. In addition to the problem inherent with delivering any high water mark file, delivering signed high water mark JAR files does not allow the integration of third-party code, that is, code not available when the JAR files are created.
Therefore, there is a need for an approach for providing a JAVA code release infrastructure. Preferably, such an approach would resolve the high water mark, patch integrity and revision control problems while supporting long file names, special characters, extended character sets, deeply nested packages, and inner classes.
There is a further need for an approach for providing granular patching of individual class files while maintaining the integrity of the source file to which the class belongs. Preferably, such an approach would include a facility to integrate third-party code into the patching process.